-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add tab focus & keyboard enter event to DrillDown & ViewDrd #802
Add tab focus & keyboard enter event to DrillDown & ViewDrd #802
Conversation
@@ -71,7 +72,7 @@ export default class DrillDown { | |||
addOverlay(element, className) { | |||
const html = domify(` | |||
<div class="drill-down-overlay"> | |||
<span class="${className}"></span> | |||
<button class="${className}"></button> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the span element doesn't capture ENTER key, I've changed this element to a Button which does capture it. Also removed the outline style override to allow native button outline to be displayed on button focus.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We still need to fix styling here. Also, if the drilldown is not enabled (e.g. for DRD-only viewer), this should remain to be a span
as it's not interactive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added type=button
because otherwise it's type=submit
which is not correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We still need to fix styling here.
Yeah good point, about the styling added a comment here and a commit -> #802 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, if the drilldown is not enabled (e.g. for DRD-only viewer), this should remain to be a span as it's not interactive.
Is there some state or property we can check for "DRD-only viewer" mode? Then we could just add a conditional to render either a span or button within the addOverlay()
function:
let html;
if (isDrdOnlyMode) {
html = domify(`
<div class="drill-down-overlay">
<span type="button" class="${className}"></span>
</div>
`);
} else {
html = domify(`
<div class="drill-down-overlay">
<button type="button" class="${className}"></button>
</div>
`);
}
// then | ||
expect(drillSpy).to.have.been.calledOnce; | ||
|
||
expect(drillSpy).to.have.been.calledWith(overlayEl); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Working on fixing this test, at the moment overlayEl does return the button element, but the drillSpy is not called in test. After the ENTER key event has been triggered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't able to fix this test too. It looks like in Chrome the synthetic keyboard event for enter doesn't trigger "click" handler, but a trusted keyboard event does. So this won't work:
const event = new KeyboardEvent('keydown', {
key: 'Enter',
code: 'Enter',
which: 13,
keyCode: 13,
});
mybutton.dispatchEvent(event);
We could add an event handler for Enter (and also Space), or just trust in browser behavior, and leave it untested.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah seems fine to skip this test, as the browser will trigger the click event on a button element by default on ENTER key event.
Hi, thanks for opening this PR and sorry that you had to wait for so long. I will look into this today. |
@@ -71,7 +71,7 @@ export default class DrillDown { | |||
addOverlay(element, className) { | |||
const html = domify(` | |||
<div class="drill-down-overlay"> | |||
<span class="${className}"></span> | |||
<button type="button" class="${className}"></button> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The styling is not quite there yet. I'd rather keep the old look for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@barmac can you explain a bit more about the styling? I guess you mean that the previous blue background is missing on the new button element.
After:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've pushed a new commit to match the styling that was there previously on the span.
What do you think? __34041ad
Without focus
With focus
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I meant is that if we switch to standard button look, we change the visuals significantly. On the other hand, we need some way to indicate focus.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@barmac I've pushed another commit so the focus style is more apparent on the drill down button.
Do you see some specific style difference between original and new style as described below?
If so I can try to adjust it further to match the expectation.
For comparison this is the original span style on focus, i.e, no focus focus style applied just span with blue background:
===
Whereas below, this is the latest commit blue button which IMO looks the same as original span style, but with the browser focus style being applied:
Before Focus (default style)
Focused (Dark blue focus style applied by browser)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, it looks better now. I will tweak it a bit and then merge this PR :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, looking forward to the next release then :)
ac556c6
to
e3d7e14
Compare
I just noticed that we set the icon DOM element to be a button even if it's not clickable. I will fix that. |
OK I played a bit with CSS, and also made sure that we display I built a demo website which can be accessed at https://dmn-js-a11y-demo.netlify.app/ Screen.Recording.2023-12-06.at.16.57.36.mov |
I tested this additionally on Firefox, and the focus there is even harder to notice. What we need to remember is that this PR is just a first step. We can do much more for the accessibility of the tools. For example, the a11y tools don't announce the element which is focused. However, I think it's still better to have some improvement than no-solution as it is without this contribution. |
Increase outline offset looks good on Firefox: Screen.Recording.2023-12-07.at.13.49.20.movand in Chrome: Screen.Recording.2023-12-07.at.13.50.16.mov |
…wnComp: Apply tabindex=o attribute to catch keyboard focus & change element from span -> button to capture enter enter key event and drill down
…us, .view-drd-button: Remove outline: none style to allow browser native focus style to be applied to button
…r tab focus style is visible (.djs-overlay .drill-down-overlay)
…r tab focus style is visible (.djs-overlay .drill-down-overlay)..remove style prop
16ad122
to
35100ba
Compare
Thank you for raising the accessibility issue, @marstamm . I think there are three ways we could address it:
Otherwise, this looks good to me. |
Thanks @BrianJVarley for initiating this and everybody else for feedback! :) |
@marstamm @barmac I've noticed also using screen reader that the view / hide DRD buttons don't have an aria-label. I think it would improve the accesibility to label these buttons also for example "Show DRD" / "Hide Diagram" |
Thanks for the feedback. Indeed, right now the user does not hear what the button action is. This could be something like View decision table/literal expression of {name}. |
ViewDrd
: Remove button outline style override, allow native browser focus style to be applied on focusDrillDown
: Change element type to -button
to allow keyboard focus and capture ENTER key event to trigger drilldown.Closes #778 (💡 Discussion in progress & tests needed)